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REAL PARTY IN INTEREST 

The present application is assigned to GENERAL ELECTRIC CAPITAL 
CORPORATION, 3135 Easton Turnpike, Fairfield, CT 06828, U.S.A. 

RELATED APPEALS AND INTERFERENCES 

No other appeals or interferences are known to Appellants, Appellants' legal 
representative, or assignee, which will directly affect, be directly affected by, or have a bearing 
on the Board's decision in the pending appeal. 

STATUS OF CLAIMS 

Claims 4-8, 10-12, 14-19, 21, 23-32, 37-40 and 46-67 are pending in this application. All 
pending claims stand rejected and are now being appealed. 

Claims 1-3, 9, 13, 20, 22, 33-36 and 41-45 have previously been canceled. 

STATUS OF AMENDMENTS 

The Amendment after final action submitted herein on November 23, 2005 is entered for 
purposes of this appeal as per paragraph 7 of the Advisory Action issued herein on December 19, 
2005. The statement of the "Status of Claims" provided immediately above reflects the 
Amendment after final action. 

SUMMARY OF CLAIMED SUBJECT MATTER 

In some computing environments, a number of different legacy application programs may 
run on a computer system. The proprietor of the computer system may wish to provide outside 
customers with remote access to the functionality of the legacy programs via a single, consistent 
user interface, but differences among the application programs, such as differing logic models, 
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may make it difficult to achieve this goal by combining the functionality of the legacy 
applications into a single new application. (Specification, page 1, line 20 to page 2, line 1) 

According to the present invention, legacy applications are treated as sub-applications to 
which a common context is provided to allow the sub-applications to function together 
cooperatively as a single application, notwithstanding that the sub-applications may have 
disparate logic models. (Specification, page 2, lines 14-18) A dispatching system provides a 
common interface for the sub-applications, and receives HTTP requests to be serviced by one or 
more of the sub-applications. (Specification, page 2, line 25 to page 3, line 3) The HTTP 
requests are from client computers and each includes a URL. (Specification, page 4, lines 24-26 
and page 3, lines 7-8) 

For each sub-application there is a match criteria that is a regular expression related to the 

URL. (Specification, page 3, lines 3-8) If the match criteria for a sub-application matches the 

request, the request is dispatched to the sub-application for invocation of a service routine that is 

included in the sub-application. (Specification, page 3, lines 9-12) 

******* 

Appellants will next set forth the corresponding structure or acts described in the 
specification for each of the means plus function and step plus function limitations of the 
independent claims as well as for dependent claims that are separately argued herein. 

Claim 4 (independent) 

"Providing a context for the sub-applications" — specification, page 2, lines 16-18. 

"Receiving a request from a client computer to perform a service" — specification, page 3, 
lines 1-3; and page 4, lines 24-26. 

"Determining whether the received request should be dispatched to the sub- 
application" — specification, page 3, lines 5-7. 

"Invoking a service routine of the sub-application passing the request" — FIG. 4 (block 
407); specification, page 3, lines 11-12, page 12, lines 5-7. 

"Determining whether a match criteria for the sub-application matches the received 
request" — FIG. 4 (block 405) specification, page 3, lines 9-12, page 12, lines 2-4. 
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Claim 37 (independent) 

"A plurality of service means for servicing requests" — FIG. 1 (web server 103); FIG. 2 
("perform service" sub-applications 214, 223); specification, page 4, lines 20-21, page 5, lines 
12-15, 21-24, page 5, line 30 to page 6, line 2. 

"Dispatch means for receiving requests from client computers, evaluating match criteria 
to identify which service means have match criteria that match the requests, and invoking the 
identified service means" — FIG. 1 (web server 103; dispatcher 105); specification, page 4, lines 

20- 24, 28-30, page 5, line 30 to page 6, line 2. 

Claim 46 (independent) 

"Receiving a request from a client computer to perform a service" — specification, page 3 ? 
lines 1-3; and page 4, lines 24-26. 

"Retrieving a match criteria for the service routine" — FIG. 3 (block 309); specification, 
page 11, lines 23-24. 

"Determining whether the received request matches the retrieved match criteria" — FIG. 4 
(block 405); specification, page 12, lines 2-4. 

"Invoking the service routine for processing of the received request" — FIG. 4 (block 
407); specification, page 12, lines 5-7. 

Claim 54 (dependent on claim 4, also argued separately) 

"A respective service routine is invoked for the request with respect to each of at least 
two of the sub-applications" — FIG. 2 (sub-application sequence 210); specification, page 5, lines 

21- 30. 

Claim 59 (dependent on claim 54, also argued separately) 

"The sub-applications are ordered and the invoking of the service routines of the at least 
two sub-applications is performed in the order of the sub-applications" — specification, page 4, 
lines 5-9. 
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GROUND OF REJECTION TO BE REVIEWED ON APPEAL 



Claims 4-8, 10-12, 14-16, 21, 23-32, 37-40 and 46-67 are rejected under 35 U.S.C. § 
102(e) as being anticipated by Limprecht (U.S. Patent No. 6,813,769). 1 



ARGUMENT 



/. A pplicable Law 

All of the issues in this appeal are related to rejections, formulated under 35 U.S.C. § 
102(e), in which the Examiner contends that the claimed invention is anticipated by the 
Limprecht reference. The law governing anticipation is set forth as follows in Verdegaal Bros, v. 
Union Oil Co. of California, 814 F.2d 628, 631 (Fed.Cir. 1987), as quoted in MPEP § 2131 : 

A claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a single prior art 
reference. 

Moreover, "[t]he identical invention must be shown in as complete detail as is contained 
in the ... claim." 

As appellants will demonstrate, the Limprecht reference fails to satisfy the "all elements" 
rule, and the Examiner's anticipation rejection fails to deal with the claimed invention in 
"complete detail". 



The Examiner also stated a rejection under § 103(a) of claims 17-19, which are dependent on claim 4 and for the 
purposes of this Brief are intended to stand or fall with claim 4. The rejection of claims 17-19 relies on a 
combination of Limprecht with Underwood (U.S. Patent No. 6,718,535). The Underwood reference does not appear 
to raise any issue with respect to the patentability of claim 4, was not cited by the Examiner against claim 4, and 
accordingly will not be discussed in this Brief. 

2 Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236 (Fed.Cir. 1989) [also quoted in MPEP § 2131; emphasis in 
quotation has been added]. 
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//. Detailed discussion of the novelty of claim 4 

Claim 4 is taken as representative of all of the independent claims now presented in the 
application. Thus appellants propose that the novelty of claim 4 also establishes novelty as to all 
of the pending claims. As will be seen, certain of the dependent claims will also be separately 
argued. 

A. Particularly pertinent features of claim 4 

In accordance with the above description of the invention in the "Summary of Claimed 
Subject Matter", claim 4 calls for an HTTP request from a client computer to be dispatched to a 
sub-application when a match criteria for the sub-application matches the HTTP request. 
Further, claim 4 specifies that the HTTP request has a URL 3 , and that the match criteria for the 
sub-application "is a regular expression relating to the URL". 4 As will be demonstrated 
hereinafter, the Limprecht reference fails to show match criteria of this nature, and the Examiner 
has apparently not taken this detail of claim 4 properly into account in formulating his 
anticipation rejection. 

B. Overview of the Limprecht reference 

The Limprecht reference is primarily concerned with improving the efficiency of 
operation of a component-based server computer application. 5 The primary strategy employed in 
Limprecht' s system to improve efficiency, and hence scalability, of the server application is to 
minimize the state duration of instances of the application components by causing the instances 



"Uniform resource locator", as defined at page 3, line 8 of the specification and as commonly understood by those 
who use the Internet. 

4 Examples of such match criteria are set forth in the specification at page 3, line 7 and page 5, line 10 to page 6, 
line 8. 

5 See Limprecht reference, Abstract and column 3, lines 38-48. 
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of the components to be destroyed or disassociated from the client reference after return from the 
client program's call. 6 

In its aspects that appellants believe are most nearly pertinent to the present patent 
application, Limprecht discloses that a client program can request creation of a desired server 
application component by using the CLSID (class identifier) of the service application 
component and an IID (interface identifier) of the desired interface of the desired server 
application component. As discussed below, it now appears that the Examiner considers the 
CLSID to correspond to the "match criteria" recited in claim 4, but it is notable that a CLSID is 
not related in any way to a URL included in a HTTP request. 

Stepping back for a moment to view Limprecht' s system and the present invention in a 
broader context, appellants observe that the respective problems addressed by Limprecht and by 
the present inventors are quite different. The present invention is concerned with joining 
together disparate legacy applications programs so that all may be accessed via a common 
interface, whereas Limprecht is concerned with improving the efficiency and scalability of a 
server application. Given this difference in objective, it is not surprising that the respective 
software systems of Limprecht and of the present inventors differ in significant details. As 
explained in this Appeal Brief, appellants believe that the independent claims now presented in 
this patent application are sufficiently narrow so as to recite at least some detail that is not 
disclosed by the Limprecht reference. 

C. Posture of this patent application at the time of appeal 

Appellants will now summarize the recent procedural history of this patent application in 
order to shed light on what appear to be the Examiner's contentions in regard to the currently 
presented independent claims. Appellants believe the following discussion will also place in 
sharp relief the present difference in viewpoint between appellants and the Examiner. 

In the Final Office Action dated August 9, 2005, which appellants now explicitly appeal 
from, the Examiner addressed claim 4 (then a dependent claim) by asserting that "Limprecht 

6 See Limprecht reference, column 3, lines 48-65. 

7 See Limprecht reference, column 12, lines 41-48, column 13, lines 4-7, column 12, lines 57-60, and column 13, 
lines 2-3. 
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teaches the requests are HTTP requests with a URL and the match criteria is a regular expression 
relating to the URL". 8 In alleged support of this assertion, the Examiner cited a passage at 
column 6, lines 38-65 of Limprecht. In the Amendment after final action filed herein on 
November 23, 2005, appellants rewrote claim 4 in independent form without change in scope, 
and amended the other independent claims (or dropped them in favor of dependent claims) to 
make appellants' arguments in favor of claim 4 also applicable to all other independent claims 
presented in the Amendment after final action. The appellants went on to traverse the latter part 
of the above quoted contention by the Examiner, by pointing out that "the Limprecht reference 
fails to teach a match criteria that is a regular expression relating to the URL of an HTTP 
request". Appellants went on to explain that the passage cited by the Examiner 

does not support the Examiner's reliance thereon 9 , since the 
passage only describes in general terms a networking environment 
in which Limprecht' s system may be embodied. The passage does 
not relate in any way to match criteria. 10 

The appellants also commented in regard to the Examiner's treatment of claim 3 11 that 
the Examiner apparently 

considered a match criteria to be whether a server application 
component supports an IObjectControl interface (citing column 21, 
lines 25-38 of the reference). Such a match criteria has nothing to 
do with a regular expression relating to a URL. 

In response to these points made by appellants in the Amendment after final action, the 
Examiner apparently shifted his ground substantially in the remarks he appended to the Advisory 
Action issued herein on December 19, 2005. Appellants will now quote in full the relevant 
portion of the Examiner's remarks in the Advisory Action, both to show that the Examiner has 

8 Page 4, paragraph 6 of the Final Office Action. 

9 Appellants should clarify at this time that the passage in the reference cited by the Examiner supports the first part 
of his contention, in regard to HTTP requests with a URL, but not the second part of his contention, in regard to 
match criteria that are a regular expression relating to the URL. 

10 See page 13, second full paragraph of the Amendment after final action. 

1 1 Dropped in the Amendment after final action in favor of claim 4, which was dependent on claim 3 at the time of 
the Final Office Action. 
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implicitly conceded that appellants' traverse of the rejection (as stated in the Final Office Action) 
of claim 4 was correct, and to show what appears to be the Examiner's current position. 
(Unfortunately, the Examiner's current position suffers from the same basic flaw as the 
abandoned contentions of the Final Office Action, that basic flaw being that the Limprecht 
reference fails to disclose a match criteria relating to a URL.) 

[AJpplicant argues that Limprecht fails to teach a match criteria 
that is a regular expression relating to the URL of an HTTP 
request. Examiner respectfully disagrees and notes that Limprecht 
teaches client-server communications over the Internet (col. 6, 
lines 50-65) and HTTP is the protocol used to carry requests from 
client to server; therefore, when the client submits a request to the 
server, the request would be a HTTP request. Limprecht teaches a 
client request to create an instance of the server application 
component (col. 12, lines 40-50) using the component's identifier 
(col. 13, lines 4-20). A component is activated if there is an 
instance of the server application component in the component 
pool (col. 21, lines 1-14) and the match criteria is that a component 
in the component pool has an identifier that matches the request 
identifier . Therefore, Limprecht teaches the invention as claimed. 
[Emphasis now added by appellants] 

The Examiner then completes his remarks by generally re-affirming the rejections stated 
in the Final Office Action, even though the Examiner has completely changed the aspects of the 
reference relied upon in regard to the claim limitation of "match criteria". 

What appellants find most notable about the Examiner's remarks just quoted is that, 
although the Examiner accurately characterizes appellants' argument, he completely fails to read 
the argued claim limitation— a match criteria that is a regular expression relating to the URL of an 
HTTP request— on the disclosure of the reference . Accordingly, even though the Examiner's 
detailed discussion of the reference is unexceptionable, his analysis of the reference is fatally 
incomplete, since he fails to recognize that his proposed "match criteria" (CLSID, column 13, 
line 6 of Limprecht) is not in any way related to a URL . In this manner, the Examiner failed to 
consider the invention contained in claim 4 in complete detail , and so failed to recognize that the 
Limprecht reference does not disclose the claim limitation of a sub-application match criteria 
that is related to a URL. 



D. Recapitulation of the errors in the pending rejection of claim 4 

By now a key difference between the invention recited in claim 4 and the software 
system disclosed in the Limprecht reference should be clear, and it only remains to summarize 
why the rejection of claim 4 should be reversed. 

The pending rejection of claim 4 should be reversed for two related reasons: (1) The 
Examiner has failed to identify any portion of the Limprecht reference that discloses the claim 
limitation of a sub-application match criteria that is related to a URL; and (2) the reference in 
fact fails to disclose this claim limitation. In Limprecht, a server application component is 
activated in response to a client software request that provides the class identifier for the server 
application component. In the invention of claim 4, a request is dispatched to a particular sub- 
application when the request matches a match criteria for the sub-application that relates to a 
URL included in the request. Even assuming that Limprecht' s server application components are 
properly considered to be "sub-applications", the reference completely fails to disclose match 
criteria related to URLs. Limprecht's server application component class identifiers, which the 
Examiner considers to be "match criteria", have nothing to do with URLs. Thus the Limprecht 
reference fails to satisfy the "all elements" rule, and does not anticipate claim 4. 

12 

III. Separate Argument in Support of Claim 54 

Claim 54 is dependent on claim 4 and adds the limitation that a respective service routine 
is invoked for the request with respect to each of at least two of the sub-applications. 

In the Final Office Action, the Examiner's treatment of claim 54 included citing a 
passage at column 22, lines 60-67 of Limprecht and summarizing that passage as teaching that 
"IObjectContext interface 139 is used by the server application component 86 to create 
additional server application components, and to participate in the determination of transaction 
outcomes". However, this passage does not state, nor does the Examiner even contend it states , 
that more than one server application component (considered to be a "sub-application" by the 
Examiner) is created in response to a single request . Thus, again, the Examiner has failed to 



The argument in this section is believed to present an additional basis for allowance of claims 54-56 and 59-63. 
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consider the claims in complete detail The asserted anticipation of claim 54 fails to satisfy the 
"all elements" rule, in that the Limprecht reference does not disclose creating two or more server 
application components in response to one client program request. The rejection of claim 54 
should be reversed on this additional ground. 

IK Separate argument in support of claim S9 13 

Claim 59 is dependent on claim 54 and adds the limitations that the sub-applications are 
ordered and that the invoking of the service routines of the at least two sub-applications is 
performed in the order of the sub-applications. 

In purportedly formulating a rejection of claim 59, the Examiner referred to a passage at 
column 18, lines 25-48 of Limprecht. However, this passage only describes pooling and 
recycling of server application instances. This passage has nothing to do with the order in which 
service routines of sub-applications are invoked. This subject also is not discussed anywhere 
else in the reference. Accordingly, claim 59 recites an additional limitation that is not disclosed 
in the allegedly anticipatory reference, and the rejection of claim 59 should be reversed on this 
additional ground. 

CONCLUSION 

The rejection of the independent claims herein is improper at least because all of those 
claims recite at least one limitation not disclosed in the Limprecht reference. The Examiner's 
decision should therefore be reversed. 

As required by 37 CFR §41 .37(a)(1), this Brief is filed within two months from the date 
of mailing of Appellants' Notice of Appeal (i.e., within two months of February 9, 2006); as 
such, no extension of time is believed due. However, if any additional fees are due in 
conjunction with this matter, the Commissioner is hereby authorized to charge them to Deposit 
Account 50-1852 . An Appendix of claims involved in this appeal is attached hereto. 



The argument in this section is believed to present an additional basis for allowance of claims 59-63. 
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*1 



If any issues remain, or if the Examiner or the Board has any further suggestions for 
expediting allowance of the present application, kindly contact the undersigned using the 
information provided below. 



Respectfully submitted, 




April 3, 2006 Nathaniel Levin 

Date Registration No. 34,860 

Buckley, Maschoff & Talwalkar llc 

Five Elm Street 

New Canaan, CT 06840 

(203) 972-3460 
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APPENDIX A--CLAIMS 

1-3. (canceled) 

4. A method in a computer system for dispatching requests to perform services to 
sub-applications that use different logic models the method comprising: 

providing a context for the sub-applications 

receiving a request from a client computer to perform a service; and 
•for a plurality of sub-applications, 

determining whether the received request should be dispatched to 

the sub-application; and 

when it is determined that the request should be dispatched to the 
sub-application, invoking a service routine of the sub-application passing the request 

whereby the sub-applications share the provided context; 

wherein the determining includes determining whether a match criteria for the 
sub-application matches the received request; 

wherein the requests are HTTP requests with a URL and the match criteria is a 
regular expression relating to the URL. 

5. The method of claim 4 including suppressing the invoking of additional 
service routines when an invoked service routine returns an indication to suppress the invoking 
of additional service routines. 

6. The method of claim 4 including suppressing the invoking of additional 
service routines when an invoked service routine responds to the received request. 

7. The method of claim 4 wherein an invoked service routine performs user 
authentication and indicates to suppress invoking of additional service routines when a user 
cannot be authenticated. 
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8. The method of claim 4 wherein an invoked service routine logs the received 

request. 

9. (canceled) 

10. The method of claim 4 wherein an invoked service routine transforms the 
received request from one protocol to another protocol. 

1 1 . The method of claim 4 including: 
for each of a plurality of sub-applications, 

retrieving initialization parameters for the sub-application; 
retrieving an indication of a class for the sub-application; and 
instantiating an instance of the class with the retrieved initialization 

parameters. 

12. The method of claim 4 wherein the determining includes determining 
whether a match criteria in a configuration file for the sub-application matches the received 
request. 

13. (canceled) 

14. The method of claim 4 wherein a sub-application uses an interaction-based 

model. 

15. The method of claim 4 wherein a sub-application uses an action- view model. 

16. The method of claim 4 wherein a sub-application uses a workflow-based 

model. 
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17. The method of claim 4 wherein the sub-applications form an overall 
application and wherein the provided context is an application-level context. 



18. The method of claim 4 wherein the sub-applications form an overall 
application that is web-based. 

19. The method of claim 4 wherein the request is received from a web-server 

environment. 

20. (canceled) 

21. A computer system for dispatching HTTP requests to sub-applications, 

comprising: 

a configuration file having a class, initialization parameters, and a match criteria 
associated with the sub-applications; 

an initialization component that instantiates an object of the class for each sub- 
application in the configuration file, the instantiated object being initialized with the initialization 
parameters for the sub-application and being provided with a context object, the context object 
being shared by the instantiated objects so that the sub-applications share a common context; and 

a dispatcher that receives HTTP requests from client computers and, when the 
received HTTP request matches a match criteria of a sub-application, invokes a service routine 
of the instantiated object of the class associated with the sub-application; 

wherein the match criteria is a regular expression relating to a URL of the HTTP 

request. 

22. (canceled) 
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23. The computer system of claim 21 wherein the dispatcher does not invoke any 
additional service routines when an invoked service routine returns an indication to not invoke 
any additional service routines. 

24. The computer system of claim 21 wherein the dispatcher does not invoke any 
additional service routines when an invoked service routine responds to the received request. 

25. The computer system of claim 21 wherein a sub-application is based on an 
interaction model 

26. The computer system of claim 21 wherein a sub-application is based on an 
action-view model. 

27. The computer system of claim 21 wherein each of the sub-applications 
implement the same interface. 

28. A computer system for processing request messages, comprising: 

a plurality of sub-applications forming an application, a sub-application having a 
match criteria indicating when the sub-application should process a request and having a service 
routine to invoke when the match criteria indicates that the sub-application should process the 
request, the sub-applications using disparate logic models; 

a context for the application that is shared by the sub-applications; and 
a dispatcher that receives requests from client computers, evaluates the match 
criteria to identify which sub-applications have match criteria that match the requests, and 
invokes the service routines of the identified sub-applications wherein invoked sub-applications 
use the context; 

wherein the requests are HTTP requests with a URL and the match criteria is a 
regular expression relating to the URL. 
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29. The computer system of claim 28 including an initialization component that 
instantiates an object of a specified class for each sub-application. 

30. The computer system of claim 29 wherein the initialization component 
accesses configuration information that specifies the class of each sub-application and any 
initialization parameters for the sub-applications. 

3 1 . The computer system of claim 29 including a context object representing the 
context and wherein the initialization component provides the context object to each sub- 
application. 

32. The computer system of claim 28 wherein each service routine is passed a 
request parameter and returns a response parameter. 

33-36. (canceled) 

37. A computer system for processing request messages, comprising: 

a plurality of service means for servicing requests, the service means forming an 
application, each service means having a match criteria indicating when the service means 
should be invoked, the service means implementing different logic models; and 

dispatch means for receiving requests from client computers, evaluating match 
criteria to identify which service means have match criteria that match the requests, and invoking 
the identified service means whereby the service means share a context that is common to the 
service means of the application; 

wherein the requests are HTTP requests with a URL and the match criteria is a 
regular expression relating to the URL. 

38. The computer system of claim 37 including an initialization means for 
instantiating an object of a specified class for each service routine. 
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39. The computer system of claim 38 wherein the initialization means accesses 
configuration information that specifies the class of each service means and any initialization 
parameters for the service means. 

40. The computer system of claim 37 wherein each service means is passed a 
request parameter and returns a response parameter. 

41-45. (canceled) 

46. A computer-readable medium for controlling a computer system to dispatch 
requests to perform services to service routines, by a method comprising: 

receiving a request from a client computer to perform a service; and 
for a plurality of service routines, 

retrieving a match criteria for the service routine; 

determining whether the received request matches the retrieved match 

criteria; 

when it is determined that the request matches the retrieved match criteria, 
invoking the service routine for processing of the received request 

whereby the service routines form an application and share a common context; 
wherein the requests are HTTP requests with a URL and the match criteria is a 
regular expression relating to the URL. 

47. The computer-readable medium of claim 46 including suppressing the 
invoking of additional service routines when an invoked service routine returns an indication to 
suppress the invoking of additional service routines. 

48. The computer-readable medium of claim 46 including suppressing the 
invoking of additional service routines when an invoked service routine responds to the received 
request. 
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49. The method of claim 4 wherein all of the sub-applications execute on the 
same server computer. 

50. The computer system of claim 21 wherein all of the sub-applications execute 
on the same server computer. 

51 . The computer system of claim 28 wherein all of the sub-applications execute 
on the same server computer. 

52. The computer system of claim 37, wherein all of the service means and the 
dispatch means are implemented on the same server computer. 

53. The computer-readable medium of claim 46 wherein all of the service 
routines are implemented on the same server computer. 

54. The method of claim 4 wherein a respective service routine is invoked for the 
request with respect to each of at least two of the sub-applications. 

55. The computer system of claim 21 wherein a respective service routine is 
invoked for at least one of the HTTP requests with respect to each of at least two of the sub- 
applications. 

56. The computer system of claim 28, wherein a respective service routine is 
invoked for at least one of the requests with respect to each of at least two of the sub- 
applications. 

57. The computer system of claim 37 wherein at least one of the requests is 
serviced by at least two of the service means. 



19 



58. The computer-readable medium of claim 48 wherein at least one of the 
requests is processed by at least two of the service routines. 

59. The method of claim 54 wherein the sub-applications are ordered and the 
invoking of the service routines of the at least two sub-applications if is performed in the order of 
the sub-applications. 

60. The computer system of claim 55 wherein the configuration file specifies an 
ordering of the sub-applications and the dispatcher invokes the service routines of the 
instantiated objects of the classes associated with the at least two sub-applications in the 
specified order. 

61 . The computer system of claim 56 wherein the sub-applications are ordered 
and the dispatcher invokes the service routines of the at least two sub-applications based on the 
order of the sub-applications. 

62. The computer system of claim 61 wherein an invoked service routine 
indicates that additional service routines should not be invoked to process the received request. 

63. The computer system of claim 61 wherein the dispatcher does not invoke 
additional service routines when an invoked service routine responds to a received request. 

64. The computer system of claim 57 wherein the service means are ordered and 
the dispatch means invokes the at least two service means based on their order. 

65. The computer system of claim 64 wherein an invoked service means indicates 
that additional service means should not be invoked to process the received request. 

66. The computer system of claim 64 wherein the dispatch means does not 
invoke additional service means when an invoked service means responds to a received request. 
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67. The computer-readable medium of claim 58 wherein the service routines are 
ordered and the invoking of the at least two service means is performed in the order of the 
service routines. 
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Appendix B - Evidence 



No evidence is being submitted with this Appeal Brief (i.e., this appendix is empty). 
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Appendix C - Related Proceedings 

No prior or pending appeals, interferences, or judicial proceedings are known to 
Applicants, Applicants' legal representative, or assignee, which may be related to, directly affect, 
be directly affected by, or have a bearing on the Board's decision in the pending appeal. 
Therefore, there are no copies of decisions rendered by a court or the Board to attach (i.e., this 
appendix is empty). 
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